Fossefallsmetodikkens begrensninger

Kontrakter som bygger på en fossefallsmetodikk, blir ofte valgt i store IT-prosjekter. Fossefallskontrakter kjennetegnes ved sin lineære fremgangsmåte, hvor resultatet av prosjektet er detaljert beskrevet allerede ved kontraktsinngåelsen og leverandøren jobber frem mot en på forhånd avtalt sluttleveranse. Normalt stiller kontrakten krav til fremdrift og det er avtalt fastpris.

Fossefallsmetodikken har en rekke begrensninger, og erfaringer viser at den ofte passer dårlig i store og komplekse IT-prosjekter. For det første er metodikken rigid, og åpner i liten grad for endringer underveis i utviklingsperioden, med mindre det gjennomføres formell endringshåndtering. Kravspesifikasjonen definerer hva som skal leveres, og både kunden og leverandøren må som utgangspunkt forholde seg til den samme spesifikasjonen i hele kontraktsperioden. Den detaljerte kravspesifikasjonen på bestillingstidspunktet tar av naturlige årsaker ikke høyde for læring underveis i prosjektet eller endringer i teknologien, og kunden risikerer derfor at løsningen som leveres er delvis utdatert allerede på leveransetidspunktet.

For det andre må kunden legge ned betydelig med både tid og ressurser for å utforme detaljerte kravspesifikasjoner. For kunder som ikke selv sitter på god og oppdatert teknisk kompetanse, kan det være krevende å gjøre dette nødvendige forarbeidet på en tilfredsstillende måte, uten å bruke lang tid og betydelige ressurser på å kjøpe inn ekstern ekspertise.

For det tredje er mange IT-systemer det vi kan kalle «sosiotekniske systemer» – teknologien skal fungere i samspill med mennesker og måten vi jobber på. Implementering av sosiotekniske systemer krever kontinuerlig læring og tilpasning underveis i spesifikasjons- og utviklingsperioden, noe fossefallsmetodikken i liten grad legger til rette for.

For det fjerde er det vanskelig for leverandører og kunder å få god forståelse for hverandres behov og muligheter gjennom en rigid anskaffelsesprosess. Normalt vil kundens modenhet på egne behov og kunnskap om mulighetene som finnes i leverandørens løsninger være lavere tidlig i prosjektet, på det tidspunktet spesifikasjonen «låses» i kontrakten. I en ideell prosess vil leverandøren og kunden lære av hverandre gjennom spesifikasjons- og utviklingsperioden, men dette legger fossefallsmetodikken i liten grad opp til.

Et ønske om trygghet

Med ovennevnte utfordringer som bakgrunn, kan man spørre seg hvorfor kontrakter som bygger på fossefallsmetodikken likevel blir valgt i store IT-prosjekter. En sentral del av svaret ligger nok i kundens ønske om trygghet. Gjennom detaljerte kravspesifikasjoner ønsker kunden forutsigbarhet om hvilken løsning som skal leveres, og en mulighet for å peke på leverandøren hvis løsningen ikke oppfyller de avtalte kravene.

To rettssaker om heving av store IT-kontrakter fra de senere årene viser likevel at det ikke nødvendigvis er rett frem for en kunde å komme seg ut av en kontrakt der leverandøren ikke oppfyller de fastsatte kravene. Den ene saken gjaldt heving av avtale om levering av et ERP-system mellom kunden Felleskjøpet og leverandøren Infor.^{(1)Avgjort i Eidsivating lagmannsretts dom 13. juli 2021. Lovdata: LE-2018-76187-3.} Den andre saken gjaldt heving av avtale om levering av IKT-løsning for innkreving av bompenger mellom kunden Statens vegvesen og leverandøren IBM, også omtalt som «Grindgut-saken».^{(2)Avgjort i Borgarting lagmannsretts dom 14. oktober 2022. Lovdata: LB-2020-82571-2.} I begge disse sakene tapte kundene til slutt saken, og hevingene ble ansett urettmessige. Sakene er redegjort for i tidligere utgaver av Lov&Data, se utgave nr. nr. 154 2/2023, nr. 152 4/2022 og nr. 147 3/2021. Vi vil derfor kun trekke ut noen poenger om hvordan vi mener sakene illustrerer at fossefallskontrakter ikke nødvendigvis gir den ønskede kontraktuelle tryggheten kunden søker.

Avtalen mellom Felleskjøpet og Infor var basert på standardavtalen SSA-T, mens avtalen mellom Statens vegvesen og IBM var basert på standardavtalen PS2000. SSA-T er en klassisk fossefallskontrakt, mens PS2000 er en seriefossefallskontrakt hvor flere kravspesifikasjoner og delleveranser følger løpende i utviklingsfasen.

I begge sakene kom lagmannsrettene til at leverandørene hadde misligholdt kontrakten gjennom forsinkelser og mangler. Samtidig hadde kundene i begge sakene vist løsningsvilje og forsøkt å drive prosjektene fremover, til tross for leverandørens mislighold. Dette ble av retten vektlagt i negativ retning for kunden, ettersom denne fleksibiliteten langt på vei ble tolket som en aksept av leverandørens mislighold og avkall på misligholdsbeføyelser.

Begge sakene endte med store erstatningskrav og sakskostnadskrav i disfavør av kundene, til tross for bruken av kontrakter som i utgangspunktet skal plassere en betydelig del av leveranseansvaret på leverandørene.

Mer smidige gjennomførings­modeller som løsning?

Smidige (agile) gjennomføringsmodeller tilbyr en alternativ tilnærming som kan være bedre egnet til å håndtere kompleksiteten, behovet for å absorbere læring og usikkerheten i store IT-prosjekter. Slike kontraktstyper pålegger leverandøren en innsatsforpliktelse heller enn en resultatforpliktelse, og kunden og leverandøren forutsettes å jobbe tett sammen gjennom prosjektet for å utforme og levere den beste løsningen for kunden.

Smidige gjennomføringsmodeller har som overordnet mål å skape forretningsverdi underveis, heller enn å på forhånd fastsette en detaljert plan for prosjektet. Fokuset er fremdeles å utvikle løsninger med god kvalitet, men detaljene spesifiseres løpende og ikke før prosjektet starter. Kunden slipper samtidig å bruke mye tid og ressurser på å utforme detaljerte kravspesifikasjoner i forkant av oppstart. Kunden må riktig nok bruke ressurser underveis i prosjektet på det løpende samarbeidet med leverandøren, men vår erfaring er at dette samarbeidet gir større verdi enn ressursene som legges ned i å utforme detaljerte kravspesifikasjoner. Dessuten viser erfaringene med fossefallsmetodikken at kunden også i disse prosjektene i praksis må bruke mye ressurser på formell oppfølging av leverandøren underveis, til tross for at mye av arbeidet i utgangspunktet skal være gjort gjennom utforming av kravspesifikasjonen og kontrakten.

Smidige kontrakter

Det klare utgangspunktet for kontrakter som skal regulere smidige gjennomføringsmodeller, er at de på en tenkt ansvarslinje ligger langt nærmere bistandskontrakter enn fossefallskontraktene. Dette innebærer at disse gjennomføringsmodellene ikke er egnet for kunder som ønsker å overføre betydelige deler av det kontraktuelle ansvaret for leveransen til leverandøren. Det er likevel noen mekanismer som kan og bør legges inn i kontrakter som regulerer smidige gjennomføringsmodeller.

For det første bør kontraktene beskrive et formål med prosjektet, men kun på et veldig overordnet nivå, og uten å spesifisere konkrete krav til funksjonalitet. En sentral del av mange smidige modeller er at kunden underveis i prosjektet prioriterer funksjonaliteten som skal utvikles, og dette fungerer dårlig sammen med en kontrakt som inneholder konkrete krav til funksjonalitet.

For det andre bør gjennomføringsmodellen beskrives, slik at partene har en felles forståelse og forplikter seg til å jobbe etter samme metodikk. Dette inkluderer blant annet samspillet mellom kundens ansvar for og arbeid med produktkøen, og leverandørens ansvar for gjennomføring av detaljspesifisering, utvikling og testing i utviklingsiterasjonene (sprintene).

For det tredje bør det stilles en del ikke-funksjonelle krav som leverandøren forplikter seg til å oppfylle for all funksjonalitet som tas ut av produktkøen og inn i utviklingsiterasjonene. Dette kan eksempelvis være krav til helhetlig arkitektur, kompatibilitet, infrastruktur, sikkerhet og vedlikeholdbarhet.

Til sist bør kontrakten angi hvilke ressurser kunden og leverandøren forplikter seg til å stille med, enten dette er navngitte ressurser eller konkrete kompetanseprofiler. Hvor mye de enkelte ressursene skal jobbe må også avtales. Ettersom smidige modeller ikke er veldig rigide, må det også være mulig å opp- og nedskalere og omprioritere ressursbruken i prosjektet.

Dessverre ser vi at de standardkontraktene som er tilgjengelige i det norske markedet og som utgir seg for å understøtte smidige gjennomføringsmodeller, fremdeles inneholder elementer fra den tidligere fossefallstilnærmingen, slik at de i praksis ikke fungerer etter sin hensikt. Det er også en betydelig utfordring at det inngås kontrakter basert på fossefallsmetodikken, men hvor partene blir enige om å jobbe smidig. Hvorfor dette er problematisk, er et tema som fortjener sin egen artikkel.

En løsning for alle IT-prosjekter?

Som vi har vist ovenfor, er det mange fordeler med smidige gjennomføringsmodeller i IT-prosjekter.

Fra enkelte kunders perspektiv vil den største ulempen med denne kontraktstypen være den reduserte kontraktuelle forutsigbarheten, men i lys av utfallet i de to nevnte rettssakene kan man spørre seg om hvor reell denne forutsigbarheten har vært tidligere.

Det er ikke dermed sagt at smidige gjennomføringsmodeller er løsningen for alle typer IT-prosjekter. Metoden egner seg særlig for de store og komplekse prosjektene, hvor det er vanskelig å forutsi hvordan et best mulig sluttresultat ser ut. Det er også en viktig forutsetning at kunden har kompetanse og kapasitet til å sette opp et tilstrekkelig mottaksprosjekt på sin side, ettersom behovet for et tett og omfattende samarbeid med leverandøren er en avgjørende suksessfaktor. Fossefallsmetodikken har fremdeles livets rett, men er slik vi ser det bedre egnet for mindre komplekse og mer oversiktlige prosjekter, hvor det i mindre grad oppstår behov for endringer underveis i prosjektet.

For ordens skyld opplyses det om at Advokatfirmaet Selmer bisto Felleskjøpet i forbindelse med hevingsprosessen og rettssaken i tvisten mot Infor.